Cómo se gestionan los permisos en el repositorio de código corporativo

Información general

Icono aplicacion utilidad
Tipo de recurso
Guía
Etiquetas

Gestión de permisos en el repositorio de código

Para la gestión de permisos en Gitlab se ha optado por la implementación de un modelo de autogestión. Se deberán seguir las indicaciones marcadas en la directriz Gestión de permisos en el repositorio de código, existente en Norma de uso del repositorio de código corporativo.

¿Cómo solicito la creación del grupo raíz para un Sistema, Sistema de Información o Servicio de Apoyo?

Se deberán seguir las indicaciones marcadas en la directriz Creación del grupo raíz, existente en Norma de uso del repositorio de código corporativo.

¿Cómo solicito el alta de un usuario en Gitlab?

 El aprovisionamiento de la cuenta en el repositorio de código está automatizada. Cualquier usuario que visite el dominio del repositorio a través de su VPN y que disponga de un usuario LDAP, debe realizar un primer inicio de sesión (será fallido) en la herramienta usando su usuario LDAP. Es importante que el usuario actualice su perfil con su email y seleccione “Update profile settings” para que los cambios tengan efecto. 

Posteriormente, el usuario recibirá un email de confirmación. Una vez confirmado, el usuario podrá acceder a la instancia, aunque solo verá los grupos/proyectos internos. Para acceder a un grupo/proyecto privado, debe ser invitado por el responsable del grupo/proyecto en cuestión. 

¿Cómo gestiono los accesos a los grupos / subgrupos / proyectos? 

Existen dos roles principales que podrán invitar a nuevos miembros a un grupo o proyecto: 

  • Owner 

  • Mainteiner 

Los usuarios con dichos roles tendrán autonomía para invitar a nuevos miembros a los proyectos del grupo al que pertenecen. 

Los usuarios con rol Maintainer existentes en un grupo serán responsables de los proyectos y grupos adicionales que creen, ya que al crear un nuevo grupo se le asigna directamente el rol Owner dentro del mismo. Al añadir nuevos miembros al grupo o proyecto se deberá asignar un rol (inferior o igual a maintainer) y una fecha de expiración (ver apartado ¿se debe asignar una temporalidad a los acceso?). Esta forma de trabajar aumenta la independencia de los equipos al no tener que abrir peticiones de soporte cada vez que se quiera agregar un nuevo usuario al proyecto o cambiarle el rol. 

Los usuarios que se asignan al grupo correspondiente al Sistema de Información (SI) o Servicio de Apoyo (SA) tendrán acceso a los proyectos o grupos  de este SI/SA (ya que el rol se hereda). Si fuera necesario, se podría dar solo acceso a un proyecto concreto o dar diferentes roles (permisos) al usuario en los grupos y proyectos existentes en la estructura. 

Cuando se agrega un miembro a un grupo, el usuario hereda la membresía y el nivel de permisos del grupo padre. Este modelo permite el acceso a grupos anidados si el usuario tiene ya permisos en un grupo padre.

¿Cómo cambio el nivel de acceso a un grupo / proyecto? 

Si se desea modificar el rol de un usuario en el repositorio, es responsabilidad del propio equipo de trabajo llevar a cabo este proceso. Como se mencionó anteriormente, los usuarios del equipo con roles de maintainer u owner (si el grupo/s y/o proyectos ha sido creado por un usuario maintainer de ese grupo) tienen la capacidad y deben encargarse de esta tarea. Este usuario maintainer puede asignar rol maintainer o inferior a otros usuarios. 

¿Se debe asignar una temporalidad a los accesos? 

Las directrices a tener en cuenta respecto a la duración de los roles asignados a los usuarios de la plataforma son las siguientes: 

  • Temporalidad de asignación: la fecha de expiración debe asignarse en función del tiempo estrictamente necesario, evitando asignaciones innecesariamente prolongadas. 

  • Revisión y renovación: se sugiere realizar revisiones periódicas de las asignaciones de roles. Al programar revisiones regulares, se puede garantizar que los usuarios mantengan únicamente los roles necesarios para sus responsabilidades actuales 

  • Notificaciones de expiración: El repositorio de código enviará automáticamente una alerta por correo electrónico cuando falten 7 días para que el acceso de un usuario a un grupo o proyecto expire. Estas notificaciones servirán como recordatorio para los usuarios y administradores, permitiendo una acción oportuna para renovar o ajustar los roles según sea necesario. 

En caso de desconocer la duración que debería asignarse, se utilizarán los siguientes valores predeterminados: 

  • Maintainer: 2 años. 

  • Resto de roles: 1 año. 

Estos períodos se contarán en años naturales a partir de la fecha en que se realiza la asignación. Por ejemplo, si la acción la estamos realizando el 06/06/2021, la fecha de expiración por defecto para un "Developer" será "06/06/2022". Para los años bisiestos, las altas dadas el 29 de febrero expirarán el 1 de marzo del siguiente año. 

Desde la Oficina de Impulso DevSecOps, se implementarán mecanismos que verifiquen que los usuarios asignados a grupos/proyectos poseen una fecha de expiración y en caso contrario, tomar acciones correctoras, que pueden incluir la asignación automática de una fecha o el cambio de visibilidad a un rol con permisos más restrictivos.  

¿Cómo realizo la baja de un usuario? 

Dependiendo del tipo de baja se procederá conforme a las siguientes casuísticas: 

Baja de un grupo, subgrupo o proyecto. 

Será responsabilidad del mantainer/owner del grupo o proyecto restringir al usuario o usuarios en cuestión del lugar que corresponda. 

En caso de que el causante de la baja sea el ÚNICO Owner en el grupo raíz, este debe realizar una nueva asignación Owner. El nuevo Owner será el responsable de dar la baja al anterior. 

Baja general de la instancia de del repositorio de código (Bloqueo del usuario) 

Estas peticiones deben realizarse vía NAOS, por el Director del Proyecto, a la Oficina de Impulso DevSecOps

La categorización que debe emplearse es la siguiente:  

  • Operación: Realizar petición
  • Servicio:  DSO - Impulso DevSecOps
  • Componente: Soporte de las herramientas de apoyo DevSecOps
  • Elemento: (Sin determinar)

En el asunto de la petición se indicará: 

GITLAB] Bloqueo usuario nombre usuario 

En la descripción, se detallarán los motivos que ocasionan el bloqueo. 

¿Puedo mover un grupo / proyecto de lugar? 

Es posible realizar una transferencia de un proyecto a un grupo distinto siempre y cuando quien realiza la acción sea owner de dicho proyecto y tenga como mínimo rol maintainer en el grupo que lo desea mover. 

Si se desease realizar una transferencia de un grupo y todos los proyectos contenidos en los mismos a otro sistema, solo sería posible realizarlo si posee rol owner tanto en el grupo origen y destino. 

En caso de no poder proceder al no cumplirse las condiciones anteriores, se deberá abrir petición NAOS, en la cual se indicará el nombre del proyecto que se desea mover junto con el grupo en el que se encuentra y a qué Sistema de Información se debe de mover, es decir, el grupo al cual se desea realizar la transferencia indicando el motivo. Dicha acción se realizará previo estudio y aprobación. 

¿Es posible la eliminación de un grupo? 

Si, es posible realizar está acción. Solo la persona con el rol Owner puede realizarla, bajo su total y absoluta responsabilidad. 

Roles y permisos de usuario

Roles

A continuación, se describen los roles existentes en el repositorio de código tomando como base GitLab, con una descripción simplificada de sus acciones básicas. La configuración precisa y los permisos asociados pueden variar en función de la configuración del proyecto y la versión del repositorio utilizada:

RolDescripción
OwnerEste rol es el que asignamos a los responsables (Directores de Proyecto) del Sistema de Información. Tiene control total sobre el proyecto y los permisos de todos los demás roles, incluyendo la capacidad de eliminar el proyecto y administrar los permisos de usuario.
MaintainerEste rol permite a los usuarios gestionar el código, aprobar o rechazar solicitudes de fusión, así como realizar tareas de mantenimiento del proyecto.
DeveloperEste rol permite a los usuarios gestionar el código y enviar solicitudes de fusión, pero no puede aprobar o rechazar dichas solicitudes.
ReporterEste rol permite a los usuarios hacer comentarios e informar de problemas, pero no puede hacer cambios directos en el código.
GuestEste rol permite a los usuarios ver el proyecto y los archivos, pero no puede hacer cambios.

 

Permisos de usuario

A continuación, se van a detallar algunas de las acciones que pueden realizar sobre el repositorio cada uno de los roles definidos para la estrategia de ramificación a seguir:

  • Gestión de subgrupos: crear, borrar y editar grupos hijos del grupo raíz.​
  • Gestión de miembros del proyecto: crear, borrar y editar usuarios en el proyecto.​
  • Gestión del proyecto: crear, borrar y editar proyectos.​
  • Gestión de ramas: crear, borrar y editar las ramas de un proyecto.​
  • Gestión de tags: crear, borrar y editar tags en el proyecto.​ Modificaciones en ramas: hacer commit y push sobre una rama.​
  • Fusiones en todas las ramas: Realizar merge en todas las ramas, incluye merge de los conflictos en una fusión. ​
  • Crear y aprobar solicitudes de fusión (MR): crear y aprobar Merge request.​
  • Permiso de lectura: solo tiene permiso de lectura en el proyecto. Así que solo podrá ver las ramas, pero no realizar cambios sobre ellas. 

En la siguiente tabla se puede observar la relación de permisos existentes con el rol del usuario.

 GuestReporterDeveloperMaintainerOwner
Invitar usuarios a grupos    X
Crear subgrupos   XX
Eliminar subgrupos    X
Invitar usuarios a subgrupos    X
Invitar usuarios a proyecto   XX
Gestión del proyecto   XX
Gestión de ramas*  XXX
Gestión de tags  XXX
Fusiones en todas las ramas   XX
Crear solicitudes de fusión (MR)  XXX
Aprobar solicitudes de fusión(MR)   X**X
Permisos de lecturaX***XXXX

* Sólo en las ramas feature y hotfix

** Sólo en la rama pru

*** Sólo en proyectos públicos